Social network site including interactive digital objects

ABSTRACT

A social network site with enhanced user interaction functionality. In one implementation, a method includes providing a personal page corresponding to a first user, wherein the personal page includes a digital pet module region comprising a representation of an animate object, an indicator of a current state of the animate object, an action selector control, and an action history comprising a user identifier of a previous user and an action selected by the previous user using the action selector control; receiving an indication of a selected action from a current user; modifying the state of a digital pet object based on the selected action; and causing a browser client to render the digital pet module region, the modified state, and an updated action history including an identification of the current user and the action selected by the user.

TECHNICAL FIELD

The present disclosure generally relates to social network sites.

BACKGROUND

Interactive systems connected by wide area networks, such as theInternet, have steadily evolved into vibrant mediums for socialinteraction. For example, social network sites are fast growingphenomena that provide an interactive medium through which users cangrow a network of friends for sharing personal information, as well asfor exchanging digital media such as music and videos. Social networksites have become an increasingly influential part of contemporarypopular culture around the world. A social network site focuses on thebuilding and verifying of online social networks for communities ofpeople who share interests and activities, or who are interested inexploring the interests and activities of others. Most social networkservices are primarily web based and provide a collection of variousways for users to interact, such as chat, messaging, email, video, voicechat, file sharing, blogging, discussion groups, and the like.

In general, social networking services, such as MySpace, Facebook andBebo, allow users to create a profile for themselves. Users can upload apicture of themselves and can often be “friends” with other users. Inmost social network sites, both users must confirm that they are friendsbefore they are linked. For example, if Alice lists Bob as a friend,then Bob would have to approve Alice's friend request before they arelisted as friends. Some social network sites have a “favorites” featurethat does not need approval from the other user. Social networks usuallyhave privacy controls that allow the user to choose who can view theirprofile or contact them. In connection with social network sites, userstypically create personalized web pages that display personalinformation about the users (e.g., name, age, gender, location, etc.).The user may include text, images, photos, and other content to sharewith other users. The user may periodically add or change content to thepersonalized web page after it is created.

SUMMARY

The present invention provides a method, apparatus, and systems directedto a social network site with enhanced user interaction functionality.In particular implementations, the present invention providesinteractive digital objects that facilitate or stimulate userinteraction within a social network site. In one implementation, thesocial network site provides a pet module. When invoked, the pet modulerenders an object that is a representation of a living being (e.g., apet) in a pet module region. In particular implementations, the petmodule facilitates social interaction with one another's personal pagesby allowing users to interact with the pet. In another implementation,the social network site provides a semi-autonomous digital object thatattaches itself to a personal page profile. In a particularimplementation, the semi-autonomous digital object manifests itself as ahot potato that obscures one or more regions of a user's personal page.When invoked, the hot potato module renders an object that is arepresentation of a potato. In particular implementations, the hotpotato module facilitates social interaction with one another's personalpages by allowing users to throw the hot potato to other users.

DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example network environment in which particularimplementations may operate.

FIG. 2 illustrates an example computing system architecture, which maybe used to implement a physical server.

FIG. 3 illustrates example social network site components which may beused to implement particular functionalities described herein.

FIG. 4 illustrates an example personal page.

FIG. 5 illustrates an example data table.

FIG. 6 illustrates an example key table for a given user.

FIG. 7 illustrates an example permission table for a given user.

FIG. 8 illustrates an example process flow associated with creating apersonal page.

FIG. 9A illustrates an example process flow associated with modifying apersonal page using Asynchronous JavaScript and XML (Ajax).

FIG. 9B illustrates an example process flow associated with modifying apersonal page without using Ajax.

FIG. 10 illustrates an example page for setting permissions of a userprofile.

FIG. 11 illustrates a process flow associated with setting permissions.

FIG. 12 illustrates an example page showing a revision history for aparticular user.

FIG. 13 illustrates an example page showing details of changes made byparticular users.

FIG. 14 illustrates a process flow associated with displaying a revisionhistory.

FIG. 15 illustrates an example page showing updates from all of thecontacts of a given user.

FIG. 16 illustrates a process flow associated with displaying a revisionhistory.

FIG. 17 illustrates a user interface including an example interactivedigital pet object.

FIG. 18 illustrates a user interface including showing an exampleinteractive pet object and an action selector control.

FIG. 19 illustrates a process flow associated with invoking a petmodule.

FIG. 20 illustrates a page showing an example semi-autonomous hotpotato.

FIG. 21 illustrates a page showing an example hot potato and trail ofashes information.

FIG. 22 illustrates a process flow associated with a decision totransfer a hot potato.

FIG. 23 illustrates a process flow associated with transferring a hotpotato.

DESCRIPTION OF EXAMPLE EMBODIMENTS A. Example Network SystemArchitecture A.1. Example Network Environment

FIG. 1 illustrates an example network environment in which particularimplementations may operate. Particular implementations of the inventionoperate in a wide area network environment, such as the Internet. AsFIG. 1 illustrates, a particular implementations of the invention mayoperate in a network environment comprising a social network site 20that is operatively coupled to a network cloud 60. Network cloud 60generally represents one or more interconnected networks, over which thesystems and hosts described herein can communicate. Network cloud 60 mayinclude packet-based wide area networks (such as the Internet), privatenetworks, wireless networks, satellite networks, cellular networks,paging networks, and the like. Client nodes 82 and 84 are operablyconnected to the network environment via a network service provider orany other suitable means. Client nodes 82 and 84 may include personalcomputers or cell phones, as well as other types of mobile devices suchas lap top computers, personal digital assistants (PDAs), etc.

Social network site 20 is a network addressable system that hosts asocial network application accessible to one or more users over acomputer network. The social network application may include web siteand server functionality where users may request and receive identifiedweb pages and other content over the computer network. The socialnetwork application may also allow users to configure and maintainpersonal web pages.

In particular implementations, social network site 20 comprises one ormore physical servers 22 and one or more data stores 24. The one or morephysical servers 22 are operably connected to computer network 60 via arouter 26. The one or more physical servers 22 host functionality thatallows users to interact with the social network, such as uploading andretrieving content from client nodes 82 and 84. In one implementation,the functionality hosted by the one or more physical servers may includeweb or HTTP servers, FTP servers, and the like.

Physical servers 22 also host functionality directed to a social networksite 20 described herein. In one implementation, a data store 24 maystore user account information, including core information such as useridentifiers, passwords, names, etc., as well as other user relatedinformation such as user profile data, addresses, preferences, financialaccount information, pointers to uploaded content and pointers to one ormore modules for processing content, etc. A given data store 24 may alsostore content such as digital content data objects and other mediaassets. A content data object or a content object, in particularimplementations, is an individual item of digital information typicallystored or embodied in a data file or record. Content objects may takemany forms, including: text (e.g., ASCII, SGML, HTML), images (e.g.,jpeg, tif and gif), graphics (vector-based or bitmap), audio, video(e.g., mpeg), or other multimedia, and combinations thereof. Contentobject data may also include executable code objects (e.g., gamesexecutable within a browser window or frame), podcasts, etc.Structurally, content data store 24 connotes a large class of datastorage and management systems. In particular implementations, contentdata store 24 may be implemented by any suitable physical systemincluding components, such as database servers, mass storage media,media library systems, and the like.

A.2. Example Server System Architecture

The server host systems described herein may be implemented in a widearray of computing systems and architectures. The following describesexample computing architectures for didactic, rather than limiting,purposes.

FIG. 2 illustrates an example computing system architecture, which maybe used to implement a physical server. In one embodiment, hardwaresystem 200 comprises a processor 202, a cache memory 204, and one ormore software applications and drivers directed to the functionsdescribed herein. Additionally, hardware system 200 includes a highperformance input/output (I/O) bus 206 and a standard I/O bus 208. Ahost bridge 210 couples processor 202 to high performance I/O bus 206,whereas I/O bus bridge 212 couples the two buses 206 and 208 to eachother. A system memory 214 and a network/communication interface 216couple to bus 206. Hardware system 200 may further include video memory(not shown) and a display device coupled to the video memory. Massstorage 218, and I/O ports 220 couple to bus 208. Hardware system 200may optionally include a keyboard and pointing device, and a displaydevice (not shown) coupled to bus 208. Collectively, these elements areintended to represent a broad category of computer hardware systems,including but not limited to general purpose computer systems based onthe x86-compatible processors manufactured by Intel Corporation of SantaClara, Calif., and the x86-compatible processors manufactured byAdvanced Micro Devices (AMD), Inc., of Sunnyvale, Calif., as well as anyother suitable processor.

The elements of hardware system 200 are described in greater detailbelow. In particular, network interface 216 provides communicationbetween hardware system 200 and any of a wide range of networks, such asan Ethernet (e.g., IEEE 802.3) network, etc. Mass storage 218 providespermanent storage for the data and programming instructions to performthe above described functions implemented in the location server 22,whereas system memory 214 (e.g., DRAM) provides temporary storage forthe data and programming instructions when executed by processor 202.I/O ports 220 are one or more serial and/or parallel communication portsthat provide communication between additional peripheral devices, whichmay be coupled to hardware system 200.

Hardware system 200 may include a variety of system architectures; andvarious components of hardware system 200 may be rearranged. Forexample, cache 204 may be on-chip with processor 202. Alternatively,cache 204 and processor 202 may be packed together as a “processormodule,” with processor 202 being referred to as the “processor core.”Furthermore, certain embodiments of the present invention may notrequire nor include all of the above components. For example, theperipheral devices shown coupled to standard I/O bus 208 may couple tohigh performance I/O bus 206. In addition, in some embodiments only asingle bus may exist, with the components of hardware system 200 beingcoupled to the single bus. Furthermore, hardware system 200 may includeadditional components, such as additional processors, storage devices,or memories.

As discussed below, in one implementation, the operations of one or moreof the physical servers described herein are implemented as a series ofsoftware routines run by hardware system 200. These software routinescomprise a plurality or series of instructions to be executed by aprocessor in a hardware system, such as processor 202. Initially, theseries of instructions may be stored on a storage device, such as massstorage 218. However, the series of instructions can be stored on anysuitable storage medium, such as a diskette, CD-ROM, ROM, EEPROM, etc.Furthermore, the series of instructions need not be stored locally, andcould be received from a remote storage device, such as a server on anetwork, via network/communication interface 216. The instructions arecopied from the storage device, such as mass storage 218, into memory214 and then accessed and executed by processor 202.

An operating system manages and controls the operation of hardwaresystem 200, including the input and output of data to and from softwareapplications (not shown). The operating system provides an interfacebetween the software applications being executed on the system and thehardware components of the system. According to one embodiment of thepresent invention, the operating system is the Windows®95/98/NT/XP/Vista operating system, available from Microsoft Corporationof Redmond, Wash. However, the present invention may be used with othersuitable operating systems, such as the Apple Macintosh OperatingSystem, available from Apple Computer Inc. of Cupertino, Calif., UNIXoperating systems, LINUX operating systems, and the like. Of course,other implementations are possible. For example, the serverfunctionalities described herein may be implemented by a plurality ofserver blades communicating over a backplane.

A.3. Example Social Network Site Functionality

FIG. 3 illustrates example functional components of a social networksite which may be used to implement particular functionalities describedherein. The social network site 20 components include a page creator302, a module executer 304 operatively coupled to a data store 306, acontact manager 308 operatively coupled to a data store 310, and aHypertext Transfer Protocol (HTTP) server.

As described in more detail below, page creator 302 generates personalpages for users based on layout information (e.g., user profileinformation, etc.) and a base template. Layout information is describedin more detail below in connection with FIG. 4. The module executer 304is configured to access modules (e.g., from data store 306) and executeone or more modules in order to obtain module information from localresources such as data store 306, from separate platforms such ascontact manager 308, or from one or more remote resource. Contactsmanager 308 manages the relationships for the users of the socialnetwork site 20, and may perform contact related functions such asaccessing friend lists, contact lists, and/or presence information fromdata store 310 or from other external data sources.

In particular implementations, each module is a functional softwareprogram (e.g., code, code objects, application, etc.) that the moduleexecuter 304 may invoke to obtain module information. For example,module executer 304 may execute a contacts module that communicates withcontact manager 308 to fetch contact information for a given user. Suchcontact information may include, for example, who is viewing thepersonal page of the user or who is currently on-line. As described inmore detail below, module executer 304 may execute other modules such asmedia player modules, revision history modules, blurt modules, videogame modules, photo modules, conversation modules, etc.

Although FIG. 3 illustrates the foregoing components as separatesystems, the functionality represented by each component may be combinedinto other systems. Furthermore, the functionality represented by eachdepicted component may be further separated. Still further,implementations of the invention may operate in network environmentsthat include multiples of one or more of the individual systems andsites disclosed herein. In addition, other implementations may operatein network environments where one or more of the system described hereinhave been omitted.

B. Managing Access to the Social Network Site

In one implementation, a user may access the social network site 20 andestablish a user account. To establish an account, the user provides aset of core information, which, in one implementation, may includeprofile data such as user identification (ID), a password, name, gender,age, a location, etc. In particular implementations, the name mayinclude a first name, a last name, alias name, etc. As described in moredetail below, once an account is established, some of the coreinformation (e.g., name, gender, age, location, etc.) may be displayedto the public on the personal page of the user. In particularimplementations, the core information may be stored in a data store 24or in any other suitable user account database(s). After an initialauthentication, the user may be granted subsequent accessesautomatically using cookie-based mechanisms. For example, after a userhas been authenticated, social network site 20 may create or update anencrypted cookie and provide it to the client application, such as abrowser, that the user is using to access the social network site 20.The cookie is automatically appended to subsequent requests, which thesocial network site can decrypt and authenticate to validate subsequentaccesses.

In one implementation, the social network site 20 may authenticate agiven user by requiring the user to provide user-unique information suchas a user ID and password, which maps to the user account. In particularimplementations, the user ID may be authenticated using various types ofauthentication mechanisms (e.g., Yahoo ID and password, Open ID,Microsoft Passport, etc.). The social network ID may be any data stringsuch as an email address (e.g., a Yahoo! email address), an existing ornew user ID (e.g., Yahoo ID (YID)), open ID (e.g., a Uniform ResourceLocator (URL)), etc.

In one implementation, the social network site 20 may utilize one levelof identity (e.g., user ID and password) for purposes of authentication.In particular implementations, the social network site 20 may allowother users to create stub-accounts for new users and invite them tojoin. In one implementation, a stub-account may be a temporary accountthat a new user may convert into a regular user account if the new useraccepts the invitation to join. For example, in one implementation, thesocial network site 20 may set up stub-accounts for new users, where agiven user may be identified by an email address until the user logs inand claims the stub-account. In one implementation, the original socialnetwork ID (e.g., email address) may be subsequently replaced with anewly created social network ID (e.g., a Mosh ID (MUID)). As such, theuser may access the social network using the new social network ID. Inparticular implementations, each previous social network ID of the usermay become an alias ID for the current social network ID. In otherwords, the profile data of the user may be associated with an email orany other suitable data string. As such, the owner of the personal pageas well as trusted users may still access the personal page of the ownerusing the alias ID. Also, other users may locate the owner or send theowner messages or invitations using the alias ID (e.g., email address).

C. Example Personal Page

As introduced above, social network site 20 provides personal pages forusers and applies wiki-based technology to enable other users to modifythe personal page of a given user. As described above, wikifunctionality, generally, enables a given webpage to be collaborativelymodified and edited by multiple users. In particular implementations,the only users other than the owner of the personal page that may modifythe personal page of the owner are trusted users. In a particularimplementation, the owner of the personal page approves the trustedusers. In another implementation, the owner of the personal page maydefine one or more rules that automatically define a trusted user.

C.1. Elements of the Personal Page

FIG. 4 illustrates the components of an example personal page. As FIG. 4illustrates, a personal page 400 includes a core information region 402and one or more module regions 404, 405, 406, 408, and 410. As indicatedabove, the core information region 402 displays core information, which,in one implementation, may include profile data such as useridentification (ID), a password, name, gender, age, a location, etc. Inone implementation, the displayed module regions 404-410 can begenerated by module executor 304. For example, module executor 304 maybe passed a command identifying a user ID, and a module identifier (suchas a core information module). The module executor 304 may then invokemodule code or retrieve a script and construct the information to bedisplayed as a set of HTML code. The generated HTML code may then bereturned to page creator 302 for incorporation in the HTML page returnedto the requesting user.

Each module region 404-410 may display information unique and/orspecific to the module type. For example, one module region 404 maydisplay a blurt, which is a statement (e.g., word or phrase of the day)that the owner may write. In particular implementations, trusted usersmay edit the owner's blurt, and the owner may approve or reject theedit. In one implementation, the blurt module may display a blurt trailshowing the different blurts associated with a given owner. In oneimplementation, the blurt module may display a blurt aggregation pageshowing the blurts of all contacts. Another module region 405 maydisplay a pet module region showings an interactive digital pet. Wheninvoked, a pet module renders an object that is a representation of ananimated object (e.g., a pet) in a pet module region. As described inmore detail below in connection with FIGS. 17-19, the pet modulefacilitates social interaction among users by providing a structuredmechanism by which users can interact by allowing users to select anaction from an action menu to be applied to the digital pet.

Another module region 406 may display a media player for playing aselected media file or media file play list including music, videos,etc. Another module region 408 may display a revision history log.Another module region 410 many display a slideshow of digitalphotographs uploaded by the page owner. As described in more detailbelow, the module regions 404-410 display information based on modules.In particular implementations, a module may be code sections, codeobjects, applications, scripts, etc. that include computer-readableinstructions operable to cause a processor to perform a set of actions.Using a player module as an example, the player module may cause aprocessor to fetch and play music from a local or internal source. Theplayer module may provide user controls on a player displayed in theplayer module region (e.g., module region 404).

C.2. Generating and Modifying a Personal Page

As described in more detail below, the owner and trusted users maymodify the personal page of the owner by adding or removing modules,moving module locations, and/or by modifying information in regions ofexisting modules. The social network site 20 performs the changes byupdating one or more data structures, such as table entries thatdescribe various attributes of the module information associated withthe owner of the personal page. For example, in particularimplementations, the social network site 20 may utilize a data tablethat stores user associated data (e.g., user profile data), a key tablefor looking up information in the data table based on keys, and apermission table for storing permissions.

C.2.a. Data Table

FIG. 5 illustrates an example data table. As FIG. 5 shows, the datatable includes multiple table entries, each including informationdirected to one or more attributes of a personal page or a moduleassociated with a personal page. In one implementation, the first columnshows owner fields. For ease of illustration, the data table shown inFIG. 5 shows a single owner. As such, the data in the same row of theindicated owner is associated with the personal page of that owner. Thedata table may include other entries associated with the owners of otherpersonal pages. Alternatively, in particular implementations, a uniquedata table may be partitioned from each owner.

In one implementation, the data table may include editor fields, whichshow which user has modified or attempted to modify the personal page ofthe owner (i.e., the other fields of that row). As FIG. 5 shows theeditor may be the owner or other users. As described above, in oneimplementation, the only users, other than the owner who may modify thepersonal page of the owner, are trusted users that have been approved orotherwise configured by the owner (e.g., friends, family, etc.).

As FIG. 5 shows, the data table also includes key fields that storekeys, which are strings corresponding to some information item. Thevalue fields store values of information associated with particularkeys. The time stamp fields indicate the time a given entry was added.The status fields indicate whether or not the owner has approved orrejected a given change, or whether the entry is obsolete. Thedifference fields store other information such as metadata or edits thatmay be associated with a given module. A given data field may also benull or empty for some module fields, depending on the specific moduleto which the entry corresponds.

In particular implementations, modifications made by users to a givenpersonal page may result in one or more entries in the data table and/orkey table. For example, referring to the first or top row, an owner “S”is the user who owns the personal page being changed, and editor “R” isthe user making the changes to that personal page. The key that waschanged (or added) is “Candy”, and the value of “Candy A” associatedwith that key at time “1.” As a subsequent time, referring to the secondrow from the top, editor “W” changed the value associated with the samekey “Candy” to “Candy B” at time “2.” As shown in the status field,owner “S” has approved the change. As such, the status field indicates“Approved.” In one implementation, once the owner has approved a givenchange, any previous entries become obsolete, as indicated in the statusfield of the first row. In one implementation, before a given change isapproved or rejected, the status field indicates “Pending.”

If the owner rejects a give change, the status field will indicate“Rejected.” In one implementation, if a given change is rejected, theassociated module region will show the previously approved value or novalue if none has been approved. In one implementation, if a givenentered value is deemed inappropriate either by the user or by policy,the change will not be initiated and the status field will indicate“Rejected.”

FIG. 5 shows other example keys such as a pet key, photo key, and layoutkey. As described in more detail below, the data table may be utilizedto add or remove modules from a personal page. This is achieved byadding a new entry to the data table. In one implementation, the valuefield associated with the key “Layout” stores data indicating whichspecific modules are to be displayed on a personal page, where themodule regions are to be positioned in the personal page, and whereother associated information is to be positioned within the moduleregion.

C.2.b. Key Table

FIG. 6 illustrates an example key table for a given user. As FIG. 6shows, the data table includes owner fields, key fields, label fields,and module fields. In one implementation, the label fields indicate thelabel that will be displayed (e.g., “Candy”), and the module fieldsindicate the module IDs of the modules associated with the key. Inparticular implementations, the fields of the key table are customizablefields. As such, key tables for different users have different fields,depending on the modules associated with the keys.

C.2.c. Permission Table

FIG. 7 illustrates an example permission table for a given user. As FIG.7 shows, the data table includes owner fields, action fields, andsetting fields. In one implementation, a given owner field may identifythe ID of the user whose profile the settings are for. In oneimplementation, a given action field may specify the type of operationsusers can perform on the page and may specify one or more potentialtarget actions (e.g., “edit module A,” “view module B,” etc.). In oneimplementation, a given setting field may contain a value thatrepresents a class of users who can perform the action(s). In particularimplementations, values for settings may include “friends,” “only me,”“anyone,” or categories of friends such as “friends” or “family.”

The following process flows describe various implementations involvingthe data table, key table, and permission table, and describe how thesocial network site utilizes information in these tables to enable users(e.g., a given owner and trusted users) to create and modify a personalpage.

In one implementation, the owner of a page can add someone as a friend,which confers editing permission on that person for the owner's personalpage under the default settings of one implementation of the system. Thefriend can then return and edit the owner's personal page. After thefriend has edited the owner's personal page, the owner can reject orapprove the change. If approved, the change stays present. If rejected,the change is removed from the owner's profile. The primary affordancefor approving or rejecting changes is a revision history page for theowner's profile, which is described in more detail below in Section D(Revision History Module). In a given implementation, permission can betoggled on or off for any given friend. In particular implementations,only friends can have permission to edit any owner's page. That is,anonymous, non-friend users cannot edit an owner's page.

C.3. Creating a Personal Page

FIG. 8 illustrates an example process flow associated with constructinga personal page in response to a user request. As FIG. 8 shows, the pagecreator 302 receives a request for a personal page (802). In oneimplementation, the request may include an owner ID corresponding to theowner of the personal page, and a requestor ID. In one implementation,the requestor ID may be the social network ID of the user requesting thepersonal page. In one implementation, the requestor may be the owner ofthe personal page. In particular implementations, the requestor may be auser who is creating the personal page for another user. The pagecreator 302 then checks the permission associated with the request(804). In one implementation, if the requesting user does not haveviewing permissions, a generic layout may be used in step 808 below.

The page creator 302 then accesses layout information (806). The layoutinformation is an encoded string that encodes layout informationassociated with the personal page. The layout information may includeone or more module identifiers and region identifiers encoded usingJavaScript Object Notation. In one implementation, the layoutinformation is defined relative to a base template. For example, thebase template may include several pre-defined regions, such as quadrantsand upper and lower regions. The layout information may define whichmodules are to be displayed in which base template region.

To access layout information, page creator 302 searches the key tablefor the layout entries corresponding to the owner of the personal page.As discussed above, as modifications are made, additional table entriesare added. In one implementation, the page creator 302 identified allmatching table entries including the layout key and finds the latestentry that has not been rejected by the personal page owner. In aparticular implementation, as page creator 302 and module executor 304retrieve data from the data table it stores the entries in a cache tofacilitate fast access for subsequent requests. For example, for a givenowner, the page creator 302 can obtain all of the associated keys,labels, and modules from the key table. Based on the keys, the pagecreator 302 can obtain all of the values and other pertinent informationfrom the data table. The page creator 302 then performs calculationssuch as sorting the data entries by key, identifying latest versions,etc. The page creator 302 then segregates data entries by module,referring to key table, and then caches the module relations, values,etc.

The page creator 302 then constructs the personal page based on thelayout information and a base template (808). To perform this step, inone implementation, the page creator 302 causes the module executer 304to execute one or more modules identified in the encoded layoutinformation associated with each module. In particular implementations,execution of different types of modules results in the generation ofHTML, scripts, and/or other code sections for inclusion in the pagereturned to the requesting user. For example, one module may return usercontacts information. Another module may fetch conversation threads.Another module may fetch player information, etc. In particularimplementations, the information may be retrieved from local sources(e.g., from local databases 306, 310, etc.) or from external sources(e.g., a web service). A contacts module may fetch user profile datasuch as contacts, etc., via the contact manager. After the modulesgenerate resulting code sections, they pass the code sections to thepage creator 302. After the page creator 302 receives the information,the page creator 302 merges the code section information with a basetemplate. The page creator 302 then returns the personal page to theclient of the owner via HTTP server 312 (810).

C.4. Modifying a Personal Page

FIG. 9A illustrates an example process flow associated with modifying apersonal page using Asynchronous JavaScript and XML (Ajax) technology.Ajax is a web development technique used for creating interactive webapplications. Ajax enables web pages to feel more responsive to users byexchanging small amounts of data with a server that performs databasetransactions behind the scenes. As such, the entire web page need not bereloaded or re-rendered each time the user requests a change. Overall,this increases the interactivity, speed, functionality, and usability ofa web page.

In particular implementations, modules and personal page functionalityhave client-side scripts, such as Ajax scripts, that allow the modulesto be modified on the client side. Ajax enables a user to quickly modifycontent in a given module region. When a user changes one or moreattributes of the personal page, an Ajax script transmits datacharacterizing the change to social network site 20. When a given changeis finalized, Ajax receives a status and implements code to carry outthe change, which may include adding HyperText Markup Language (HTML)code to the module region and rerendering the relevant portions of themodule region. In addition, the modification also results in a new datatable and/or key table entry.

As FIG. 9A shows, the HTTP server 312 receives a modification request(902) resulting from execution of an Ajax script embedded in thepersonal page. In one implementation, the modification request includesan editor ID, owner ID, module ID, module specific parameterscharacterizing the modification, etc. The page creator 302, responsiveto the request, causes the module executer 304 to invoke the appropriatemodule or code (904). In one implementation, if the requestor is not theowner of the personal page, the module executer 304 performs apermission check, referring to the permission table. For example, themodule executer 304 may determine whether the requestor is a trusteduser. In particular implementations, different modules require differentpermission checks. Permission checks are described in more detail belowin connection with FIG. 11. If the requestor has the permission to makethe change, the module executer 304 performs the requested change (e.g.,add or remove a module, edit information in an existing module region,etc.). In a particular implementation, the module executor 304 also addsa new data table and/or key table entry for the modification. Asdiscussed above, each entry includes the owner of the page, the editor,a key, a value, a time stamp, and optionally other information. The pagecreator 302 returns a status message to the client (906). On the clientside, Ajax code carries out the modification in the appropriate moduleregion of the personal page in response to receiving the status code. Inone implementation, the page creator 302 sends an HTML code snippet tothe client, and the Ajax code appends the HTML code to an existingelement on the personal page, or replaces the HTML code of the existingelement.

FIG. 9B illustrates an example process flow associated with modifying apersonal page without using Ajax. The HTTP server 312 receives an HTTPrequest requesting the modification (901) Steps 902 and 904 of FIG. 9Bare similar to steps 902 and 904 of FIG. 9A, where the HTTP server thenreceives a modification request (902), and the module executer 304invokes the appropriate module or code (904). The HTTP server thenredirects the browser back to the personal page, which is re-renderedwith the new information (907).

C.5. Setting Permissions

In one implementation, the owner of a given personal page may determinewhat aspects of the personal page may be viewed or edited, and by whom.In one implementation, only the owner may modify core profileinformation. FIG. 10 illustrates an example page for setting permissionsof a user profile. As FIG. 10 shows, the owner can select who can viewor edit the profile, or who can participate in conversations (e.g.,friends, family, anyone, etc.). FIG. 10 is merely an example and doesnot limit what permissions the owner may set.

FIG. 11 illustrates a process flow associated with determiningpermission to modify a page. The module executer 304 obtains permissioninformation associated with the owner (e.g., a permission setting forthe action) (1102). The module executer 304 then obtains therelationship of the owner and editor (1104). In one implementation, themodule executer 304 may obtain the relations from the contact manager308. The module executer 304 determines if the relationship matches thepermission (1106). For example, the relationship matches the permissionif the editor is the owner, or, if the owner has granted permission tothe editor. If there is not a match, the module executer 304 denies therequest (1108).

If there is not a match, the module executer 304 determines if thepermission for the action has been revoked. In particularimplementations, the owner may blacklist other individual users. Forexample, Alice has friends Bob and Eve. Alice has set her profile's editpermissions to “friends.” Now Bob and Eve can modify Alice's profile,but it turns out Eve likes to put malicious content on Alice's page.Alice can revoke edit permissions from Eve. Alice then adds Charlie as afriend. Charlie and Bob can modify Alice's profile (because they are“friends”) but Eve cannot (because she was blacklisted). In oneimplementation, Eve's permission setting may be stored in the contactsmanager. If the permission for the action has been revoked, the moduleexecuter 304 denies the request (1108). Otherwise, if the permission forthe action has not been revoked, the module executer 304 performs theappropriate database transaction (1112).

D. Revision History Module

In one implementation, the social network site 20 provides users with arevision history module that tracks the activity of users that view oredit the personal page of a given owner. FIG. 12 illustrates an examplepage showing a revision history for a particular user. As FIG. 12 shows,the page shows a series of edits to the user's personal page in reversechronological order from top to bottom. Each line item indicates whichmodule has been added or removed or what aspects of an existing moduleregion have been changed. Each line item also indicates if the owner hasapproved or rejected a given change, or provides a selection for theowner. For example, referring to line items 5-8 and 10 from the top, theowner has approved those changes. Referring to the second line item fromthe bottom of the page, another user has written a guestbook entry. Thefar right shows a “[Reject] [Approve]” selection, which the owner mayselect. In one implementation, the page may also provide links to showdetails of the modifications. FIG. 13 illustrates an example pageshowing details of changes made by particular users. For example, thefirst set of edits were made by another user, and the second set ofedits were made by the owner.

In one implementation, the “Approve” option may be omitted, where editsare implicitly approved and rejecting edits removes the edit. Inparticular implementations, the revision history module may provide a“Reject as Spam” action to differentiate abusive or malicious edits fromsimply unwanted edits.

FIG. 14 illustrates a process flow associated with displaying a revisionhistory. As FIG. 14 shows, the module executer 304 executes a revisionshistory module to obtain all edits from the data table for contacts towhich the owner has access (1402). In one implementation, the revisionhistory module performs a permission check during this step. In oneimplementation, the revision history module may shows only content forcontacts profiles to which the user has access (e.g., visibilitypermissions). The revisions history module then iterates over the data(1404). Specifically, in one implementation, the module executer 304identifies the relevant keys in all entries associated with the ownerand invokes a key value renderer to return a description of the edits.In one implementation, some edits such as rejected edits may be filteredout. The revisions history module then aggregates the data (1406). Inone implementation, the module executer 304 sorts the data by time stampduring the aggregation. The module executer 304 then displays the datain reverse chronological order.

In one implementation, the revisions history module determines the lasteditor for a particular module of a profile. In one implementation, therevisions history module may determine the last editor of the entirepersonal page. In one implementation, the module executer 304 maydetermine the most prolific editor.

In one implementation, the revision history module may perform a pulsefunction, where the revision history module performs a revision historyon a global basis (e.g., the edits of all of a given owner's contacts).FIG. 15 illustrates an example page showing updates from all of thecontacts of a given user. As FIG. 15 shows, for all contacts, edits aremade to the personal pages of other users.

FIG. 16 illustrates a process flow associated with displaying a revisionhistory. As FIG. 16 shows, the revision history module obtains allcontacts of a given user (1400) and then obtains all of the edits madeby the contacts to other users (1401). The revision history module thenobtains all edits from the data table for contacts to which the ownerhas access (1402). In one implementation, the revision history moduleperforms a permission check during this step. In one implementation, therevision history module may shows only content for contacts profiles towhich the user has access (e.g., visibility permissions). The revisionhistory module then iterates over the data (1404). In oneimplementation, the module executer 304 identifies the relevant keys inall entries associated with the owner and invokes a key value rendererto return a description of the edits. In one implementation, some editssuch as rejected edits may be filtered out. The revision history modulethen aggregates the data (1406). In one implementation, the moduleexecuter 304 sorts the data by time stamp during the aggregation. Themodule executer then displays the data in reverse chronological order.

E. Interactive Digital Pet Object

In one implementation, the social network site 20 provides aninteractive digital pet. In a particular implementation, the interactivedigital pet is provided as a module that a user can add to his or herpersonal page. When invoked, the pet module renders an object that is arepresentation of an animated object (e.g., a pet) in a pet moduleregion. In particular implementations, the pet module facilitates socialinteraction among users by providing a structured mechanism by whichusers can interact by allowing users to select an action from an actionmenu to be applied to the digital pet, as described below.

FIG. 17 illustrates a user interface including an example interactivedigital pet object. As FIG. 17 shows, the pet module region 405 displaysa representation of an interactive digital pet object 1702, petattribute information, and one or more action controls 1704. In theimplementation shown, the pet attribute information may include a petname, creation or birth date, a current state or mood, a history of oneor more actions taken and by whom, etc. For example, FIG. 17 shows aninteractive digital pet object 1702 with the name “The Mosh Pet” 1706,when the interactive digital pet object 1702 was created (born) “3 daysago” 1708, when the interactive digital pet object 1702 was last fed1710. The pet attribute information further includes the current state(here, “happy”) 1712, and the identity of the last action applied to theinteractive digital pet object 1702 and the user who applied that lastaction 1714. As FIG. 17 illustrates, the module region 405, in aparticular implementation, provides a thumbnail image or avatarassociated with the user, and a user identifier encoded as a hypertextlink that, when clicked, resolves to the user's personal page. WhileFIG. 17 shows one possible representation or image of a pet, otherrepresentations are possible. For example, a user may create and applycustomized pets by creating one to a plurality of images and associatingthe images, during an upload process, with a state or range of states.

In one implementation, the module region also indicates the currentstate or “mood” of the interactive digital pet object 1702. While themood shown in FIG. 17 indicates “happy”, the mood may indicate “hungry,”“sad,” “lonely,” “excited,” “tickled,” etc. In one implementation, therepresentation of the interactive digital pet object 1702 changesdepending on the mood. For example, if the mood of the interactivedigital pet object 1702 is happy, the interactive digital pet object1702 may have a smile. If the mood of the interactive digital pet object1702 is sad, the interactive digital pet object 1702 may have a frown.As described below, the actual mood of the interactive digital petobject 1702 may correspond to the aggregate of actions taken by otherusers. In particular implementations, the social network site 20maintains different images for different corresponding states or moodsin a data store. When constructing the page, a module executor 304 mayaccess the data tables discussed above to obtain the latest entry forthe interactive digital pet object 1702 of the user associated with thepersonal page and add to the HTML code that implements the pet moduleregion a uniform resource locator (URL) for the image that correspondsto the state of the interactive digital pet object 1702. In anotherimplementation, the image may be directly embedded into the page.

FIG. 18 illustrates a user interface including showing an exampleinteractive pet object 1702 and possible actions available under anaction selector control. As FIG. 18 shows, the action selector control1714 may be a pull-down menu showing various action selections. Forexample, such selections may include feed, pet, mosh, snorgle, lick,smack, poke, zap, kill, etc. In one implementation, any action taken mayeffect the status or mood of the interactive digital pet object 1702. Asindicated, the action selected by a given user will affect the mood ofthe interactive digital pet object 1702. For example, if someone pokesthe interactive digital pet object 1702, the mood might be angry. Ifsomeone feeds the interactive digital pet object 1702, the mood might behappy. As such, if the mood changes (e.g., happy), the image of theinteractive digital pet object 1702 will indicate the mood (e.g., asmile). In one implementation, the state of the interactive digital petobject 1702 may be determined based on an aggregation of actions appliedto it. In a particular implementation, the state information may bebased on the history of actions stored in the data tables discussedherein.

As discussed above, the pet module tracks who has taken an action uponthe interactive digital pet object 1702, when the action was taken, andwhat the action was. As FIG. 18 shows, in one implementation, the petmodule may display the last action taken and by what user in the moduleregion. In one implementation, the pet module may display a link to thepersonal page of the user who last interacted with the interactivedigital pet object 1702. In another implementation, the pet module maydisplay a history of the last N actions applied to the interactivedigital pet object 1702, or may optionally display links to the personalpages of all of the users who interacted with the interactive digitalpet object 1702 and their respective actions. Displaying thisinformation allows the owner to view the actions and to decide whetherto contact one or more of the users identified in the action history.For example, the page owner may reciprocate and interact with theinteractive digital pet object 1702 of the user who took the last actionor other users who took actions. In this manner, the interactive digitalpet object 1702 and history data facilitates or promotes interactionbetween users by providing a structured mechanism for interaction thatis simple and fun.

FIG. 19 illustrates a process flow associated with invoking a pet moduleusing an Ajax script implemented within the context of a browser client.As described above, Ajax is a web development technique used forcreating interactive web applications. An Ajax script can be configuredto cause a browser client to interact with a remote server to obtainadditional information that can be added to the page without having theentire page re-rendered or refreshed. As FIG. 19 shows, in response touser interaction with the interactive digital pet object 1702 byselecting an action using action selector control 1714 (e.g., feed),social network site 20 receives a module request generated by a script(e.g., Javascript) executing within the context of the page (1902). Inone implementation, the module request includes an editor ID, owner ID,module ID, module specific parameters (such as the current state of theinteractive digital pet object 1702 and the action selected by theuser). Social network site 20, responsive to the module request, causesthe module executer 304 to invoke a digital pet module (1904). In oneimplementation, when the digital pet module is invoked, it accesses thedata tables discussed above, using the module ID and owner ID as a key,to obtain state information such as current mood, last action taken andby whom, time stamp, customized image if applicable, and optionallyother information. FIG. 5 illustrates two entries for a pet object whereusers (labeled R and W, for didactic purposes) have applied actions to apet of a page owner, S. The value string includes the action taken bythe user, and the resulting state of the interactive digital object. Inone implementation, the pet module updates the data table in thedatabase by adding a new entry including the owner ID, editor ID, moduleID, action taken, a time stamp, and the new current state.

The module executor 304 may compute a new state for the interactivedigital pet object 1702 by accessing the current state of the mostrecent entry in the data tables, and computing a new state based on theaction received in the module request. For example, if the user fed theinteractive digital pet object 1702, the current mood may be changed(e.g., to a happy mood, etc.). After a new state is computed, socialnetwork site 30 returns a status message to the client identifying thenew state and possibly other information that is used to modify theinformation rendered in the pet module region (1906). On the clientside, Ajax script carries out the modification in the pet module region405 of the personal page in response to receiving the status code. Ifthe new state requires a new image, social network site 20 may alsoreturn a URL to the image corresponding to the new state. The Ajaxscript may insert the new URL into the HTML code of the module causingthe new image to be fetched and rendered. In other implementations,Javascript can be used to transmit the module request, and socialnetwork site 20 can transmit a redirection or HTTP refresh message thatcauses the browser client to refresh the rendered page by transmittingan HTTP request for the viewed page. In another implementation, clickingon the action selector control 1714 causes the browser client totransmit an HTTP request for a new page.

As discussed above, the pet module implemented by module executor 304may compute a new state for the interactive digital pet object 1702 byaccessing the current state of the most recent entry in the data tables,and computing a new state based on the action received in the modulerequest. In other implementations, the pet module implemented by moduleexecutor 304 may apply a stateful algorithm that determines a new statebased on the last N actions applied to the interactive digital petobject 1702. Additionally, in one implementation, the pet moduleprocesses the actions applied the interactive digital pet object 1702 todetermine a likeability factor (e.g., whether the interactive digitalpet object 1702 likes or dislikes a particular user and to what degree).For example, if a user A often feeds and pets the interactive digitalpet object 1702, the pet module may determine from the history ofactions associated with user A that the interactive digital pet object1702 likes the user A. In contrast, if a user B often pokes and zaps theinteractive digital pet object 1702, the pet module may determine fromthe history of user B that the interactive digital pet object 1702dislikes user B. In one implementation, the pet module may consider thenumber of times a given user has taken a particular action. For example,if the interactive digital pet object 1702 likes user A as a result ofuser A often feeding the interactive digital pet object 1702, theinteractive digital pet object 1702 would not necessarily dislike user Aif user A poked the interactive digital pet object 1702 once. However,if user A began poking and zapping the interactive digital pet object1702, the pet module would give those actions more weight in determiningthe likeability factor. In particular implementations, the pet modulemay display who the interactive digital pet object 1702 likes or doesnot like. This information can be used as another source of informationthat promotes interaction among users. For example, the page owner maycomment to another user that his or her interactive digital pet object1702 appears to like that user.

F. Hot Potato Module

In one implementation, the social network site 20 provides a hot potatomodule. When invoked, the hot potato module renders an object that is arepresentation of a hot potato in a hot potato module region. Inparticular implementations, the hot potato module facilitates socialinteraction with one another's personal pages by allowing users to throwthe hot potato to other users, as described below.

FIG. 20 illustrates a page showing an example semi-autonomous hotpotato. As FIG. 20 shows, the hot potato module region displays a hotpotato object 2002 and information 2004 associated with the hot potatoobject 2002. In one implementation, the hot potato module may render thehot potato object 2002 in the hot potato module region as shown. In oneimplementation, the hot potato module may render the hot potato object2002 as an overlay to any one or more other module regions. In otherwords, the rendered hot potato object 2002 need not be rendered in anypredefined region. In one implementation, the hot potato module mayrender other images instead of a potato. For example, the hot potatomodule may render slime that overlays other module regions. While thehot potato module may render a semi-autonomous hot potato as describedherein, the hot potato module may also render an autonomous hot potatosuch as a rendering involving a rich site summary (RSS) feed renderer,etc.

FIG. 21 illustrates a page showing an example hot potato and trail ofashes information. In one implementation, a trail of ashes list is alist of users having personal pages on which the hot potato object 2002has been rendered. As FIG. 21 shows, the hot potato module may displaythe list or trail of ashes. In one implementation, the list may includea number of users up to a predefined limit N (e.g., the last 10 users).FIG. 21 shows one specific implementation of the trail of ashes that isspecific to one instance of a hot potato object 2002. In otherimplementations, different hot potato objects may have different trailsof ashes as the hot potato objects travel through different personalpages.

FIG. 22 illustrates a process flow associated with a decision totransfer determining whether to throw a hot potato object 2002. As FIG.22 shows, in response to a user selecting to throw the hot potato object2002 to another user, the HTTP server 312 receives a throw request fromthe client of a user (2202). In one implementation, the throw requestmay include an editor ID, owner ID, module ID, etc. The page creator302, responsive to the request, causes the module executer 304 to invokethe hot potato module or code. In one implementation, when the hotpotato module is invoked, it randomly selects a contact from the contactlist of the user on whose personal page the hot potato object 2002 isrendered (2204). The hot potato module then transfers the hot potatoobject 2002 to the personal page of the selected user (2206). In oneimplementation, completion of throwing the hot potato object 2002 to therandomly selected contact may be contingent on having the permissionsrequired to add the hot potato object 2002 to the personal page of thatcontact. In one implementation, the hot potato module may perform apermission check similar to the permission check described above inconnection with FIG. 11. In one implementation, if the thrower does nothave the required permission, the hot potato object 2002 may be“deflected” back to the personal page of the thrower. In oneimplementation, when a user throws the hot potato object 2002 at anotheruser, it is possible that the hot potato module may randomly select thesame user. In other words, it is possible that the hot potato object2002 may get thrown back or stays at the personal page of the user. Inone implementation, if the hot potato module transfers a hot potatomodule to a personal page that already contains a different instance ofthe potato module, the hot potato module overwrites the older hot potatomodule with the newer hot potato module. As such, in particularimplementation, there is no more hot potatoes on the social network sitethan the number of personal pages.

In one implementation, if the owner of the current personal page onwhich the hot potato object 2002 is rendered does not attempt to throwor fails to successfully throw the hot potato object 2002 within apredetermined time period (e.g., 10 minutes), the hot potato module mayautomatically invoke itself and pass the hot potato object 2002 to arandom visitor. In implementation, the hot potato module may pass thehot potato object 2002 in a non-random manner. For example the hotpotato module may pass the hot potato object to the first or nextvisitor of the owner's personal page.

FIG. 23 illustrates a process flow associated with transferring a hotpotato object 2002. In one implementation, the hot potato moduletransfers the hot potato object 2002 from the personal page of one userto that of another user by modifying the layout key of the respectiveusers as described below. The hot potato module first creates a new hotpotato key with the target as owner (2302). In one implementation, thetarget is the randomly selected user described above (step 2204 of FIG.22), and the editor is the previous owner (e.g., the owner of thepersonal page from which the hot potato object 2002 is transferred).

The hot potato module then creates a new layout entry to remove the hotpotato module from the editor profile associated with the personal pageof the editor (previous owner) (2304). The hot potato module thencreates a new layout entry to add the hot potato module to the targetprofile associated with the personal page of the target (new owner)(2306). In one implementation, the value field in the data table mayinclude the latest owner in the trail of ashes list. In oneimplementation, the value field in the data table may not include thecurrent owner in the list, where the previous owner is added to thetrail of ashes list. As described above, the trail of ashes list is alist of users having personal pages on which the hot potato object 2002has been rendered. In one implementation, the ID if the latest owner isadded to a delimited string of user IDs for the last N users hit withthe hot potato object 2002.

As described herein, embodiments of the present invention provide anextremely interactive social network site 20 where trusted users maymodify not only their own personal page but also the personal pages ofother users. These capabilities facilitate and promote interaction amongusers thereby promoting use of the social network site 20.

The present invention has been explained with reference to specificembodiments. For example, while embodiments of the present inventionhave been described as operating in connection with HTML and HTTP, thepresent invention can be used in connection with any suitable protocolenvironment. Other embodiments will be evident to those of ordinaryskill in the art. It is therefore not intended that the presentinvention be limited, except as indicated by the appended claims. Forexample, a user may represent an organization (e.g., school, church,etc.) where the personal page is associated with the organization.

1-20. (canceled)
 21. A method comprising: providing, over a network via a computing device, a personal page of a user, said personal page comprising core information associated with profile data associated with the user and a digital module region comprising an interactive digital object, said digital module region of the personal page displaying information unique to a type of the digital object, said digital module region controlled by allowed interactions in connection with a displayed action selector within the digital module region; receiving, at the computing device, an indication of a selection from the displayed action selector, said indication corresponding to at least one of said allowed interactions; controlling, via the computing device, an action of the digital object based on said selection, said action comprising modifying a state of the digital object and the displayed information within the digital module region; and causing, over a network via the computing device, a client program to render the personal page in compliance with said controlled action.
 22. The method of claim 21, further comprising: requesting, over the network, a new uniform resource locator (URL) associated with the digital object based on the selection; and receiving, over the network, the new URL, said new URL corresponding to the modified state of the digital object, wherein said controlled action corresponds to the new URL.
 23. The method of claim 21, further comprising: generating new Hyper Text Markup Language (HTML) code for the digital module region upon receiving said selection indication, said HTML code controlling at least said action of the digital object.
 24. The method of claim 23, further comprising: creating new data table information for the personal page upon generating the new HTML code; and storing, over the network, said new data table information in a database location associated with the digital object module region for the personal page.
 25. The method of claim 21, wherein said action of the interactive digital object facilitates social interaction between the user of the personal page and at least a second user visiting the personal page, wherein said user and said second user can communicating via modifications to the interactive digital object.
 26. The method of claim 21, wherein said state modification of the digital object comprises displaying information selected from a listing consisting of: text, images, video, changes to the page layout, and changes to the digital module region information.
 27. The method of claim 21, wherein said action enables a second user to edit the interactive digital object.
 28. The method of claim 27, further comprising: communicating a request to the user of the personal page, said request comprising information associated with a requested edit of the digital object by the second user; and receiving, from the user, permission information associated with whether the edit is allowed.
 29. The method of claim 21, wherein said digital module region comprises a module selected from a list consisting of: a media player module, revision history module, blurt module, video game module, photo module and conversation modules.
 30. The method of claim 29, wherein said interactive digital object respectively comprises an interactive object selected from a list consisting of: a media object, revision object, blurt object, video game object, photo object and conversation object.
 31. A non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions, that when executed by a processor associated with a computing device, perform a method comprising: providing, over a network, a personal page of a user, said personal page comprising core information associated with profile data associated with the user and a digital module region comprising an interactive digital object, said digital module region of the personal page displaying information unique to a type of the digital object, said digital module region controlled by allowed interactions in connection with a displayed action selector within the digital module region; receiving an indication of a selection from the displayed action selector, said indication corresponding to at least one of said allowed interactions; controlling an action of the digital object based on said selection, said action comprising modifying a state of the digital object and the displayed information within the digital module region; and causing, over a network, a client program to render the personal page in compliance with said controlled action.
 32. The non-transitory computer-readable storage medium of claim 31, further comprising: requesting, over the network, a new uniform resource locator (URL) associated with the digital object based on the selection; and receiving, over the network, the new URL, said new URL corresponding to the modified state of the digital object, wherein said controlled action corresponds to the new URL.
 33. The non-transitory computer-readable storage medium of claim 31, further comprising: generating new Hyper Text Markup Language (HTML) code for the digital module region upon receiving said selection indication, said HTML code controlling at least said action of the digital object.
 34. The non-transitory computer-readable storage medium of claim 33, further comprising: creating new data table information for the personal page upon generating the new HTML code; and storing, over the network, said new data table information in a database location associated with the digital object module region for the personal page.
 35. The non-transitory computer-readable storage medium of claim 31, wherein said action of the interactive digital object facilitates social interaction between the user of the personal page and at least a second user visiting the personal page, wherein said user and said second user can communicating via modifications to the interactive digital object.
 36. The non-transitory computer-readable storage medium of claim 31, wherein said state modification of the digital object comprises displaying information selected from a listing consisting of: text, images, video, changes to the page layout, and changes to the digital module region information.
 37. The non-transitory computer-readable storage medium of claim 31, further comprising: communicating a request to the user of the personal page, said request comprising information associated with a requested edit of the digital object by the second user; and receiving, from the user, permission information associated with whether the edit is allowed, wherein said action enables a second user to edit the interactive digital object.
 38. The non-transitory computer-readable storage medium of claim 31, wherein said digital module region comprises a module selected from a list consisting of: a media player module, revision history module, blurt module, video game module, photo module and conversation modules, wherein said interactive digital object respectively comprises an interactive object selected from a list consisting of: a media object, revision object, blurt object, video game object, photo object and conversation object.
 39. A system comprising: a processor; a non-transitory computer-readable storage medium for tangibly storing thereon program logic for execution by the processor, the program logic comprising: providing logic executed by the processor for providing, over a network, a personal page of a user, said personal page comprising core information associated with profile data associated with the user and a digital module region comprising an interactive digital object, said digital module region of the personal page displaying information unique to a type of the digital object, said digital module region controlled by allowed interactions in connection with a displayed action selector within the digital module region; receiving logic executed by the processor for receiving an indication of a selection from the displayed action selector, said indication corresponding to at least one of said allowed interactions; controlling logic executed by the processor for controlling an action of the digital object based on said selection, said action comprising modifying a state of the digital object and the displayed information within the digital module region; and rendering logic executed by the processor for causing, over a network, a client program to render the personal page in compliance with said controlled action
 40. The system of claim 39, wherein said action of the interactive digital object facilitates social interaction between the user of the personal page and at least a second user visiting the personal page, wherein said user and said second user can communicating via modifications to the interactive digital object. 